Object-oriented programming systems (OOPS) such as Smalltalk, C++ and Java have become popular as software development tools. One advantage of object-oriented technology is its ability to improve reuse of code. In object-oriented programming, real world objects are represented by software entities called "objects" (also called "instances"), and states and behaviors of real world objects are defined as "attributes" and "operations" of the objects, respectively.
Object-oriented programming consists of designing and implementing objects, and specifying their interactions. An object-oriented programming system is characterized by the use of objects, classes, and concepts such as inheritance and polymorphism. An "objects" is a discrete, self-contained combination of data, together with operations on the data (typically referred to as "methods," which may be said to be "encapsulated" in the object). A "class" is an abstract characterization of a set of objects. All objects in this set may be said to belong to a particular class or to be created by the class . The term "inheritance" refers to a mechanism in an object-oriented programming language to define a new class by deriving the new class from an already existing class. The derived class is said to be inherited from the original class. The derived class may be called a subclass of the original class, which in turn may be called a superclass of the derived class. The derived class inherits all the data and methods from the existing class, but the derived class may add additional data or methods, or redefine inherited methods so that they behave differently than they do in the original class. The term "polymorphism" in object-oriented programming refers to identically-named methods having different behavior depending on the type of objects that they reference. When a method is invoked, polymorphism ensures that the appropriate operation occurs by determining at run time the object in question. Inheritance promotes code sharing, and polymorphism enables run-time binding of operations to objects.
Object-oriented technology has been used to develop business software "frameworks." A "framework" is an abstract design that describes the interaction between objects in a particular domain such as accounting, database, graphic user interface, operating system, inventory management, logistics, human resources management, etc. An accounting framework, for example, incorporates knowledge that is common to applications in the accounting domain. A user of the framework may use it to design an accounting system for a particular business, which involves designing the low-level details of the particular accounting system. An example of a such a framework for accounting systems is the ACCOUNTS software, a description of an earlier version of which may be found in Paul D. Keefer, AN OBJECT-ORIENTED FRAMEWORK FOR ACCOUNTING SYSTEMS, a Masters thesis submitted to the Graduate College of the University of Illinois at Urbana-Champaign, 1994.
ACCOUNTS is a framework, implemented in an object-oriented programming system, for making computerized business transaction processing systems. Under this framework, a user uses the ACCOUNTS system to define "accounts" and "transactions." Transactions may be considered time-stamped records, which are posted to accounts. Each account keeps track of and stores the transactions that affect it. Accounts may be, for example, inventory journals, bank accounts, employee records, etc.; while transactions may be, for example, purchases and sales transactions, deposits and withdrawals, time cards and paychecks, etc. An account may also have a set of attributes, which may be running totals computed from the transactions stored therein. For example, an inventory account may have attributes such as on-hand, sales month-to-date, and cost of goods sold month-to-date; while an employee record may have attributes such as overtime worked on this pay period, amount of salary due, hourly wage, and accrued vacation. In a particular ACCOUNTS system, the accounts, transactions and account attributes, as well as the relationship between them, are defined as a set of "business rules." For example, a business rule may specify that a sales transaction is to be processed by posting the amounts of goods sold in appropriate inventory accounts and posting the proceeds received in a cash account.
A new ACCOUNTS system, e.g., for a particular business, is designed by defining the accounts and transactions of the system, the attributes of each accounts, as well as how the transactions are processed by the accounts. (The term "ACCOUNTS" is used in this specification to refer to either the software that implement the ACCOUNTS framework, or a particular ACCOUNTS system designed by a user for a particular business.) Once an ACCOUNTS system is set up, a user may use it to, for example, create transactions and query attributes of accounts. Transactions may come from other computerized systems, such as a check-writer for an accounts payable system or a payroll system, or may be created by a user by filling out an input screen. Queries may be generated from a graphic user interface (GUI) tool, from reports such as bank statements or monthly reports of sales, or from computer programs that create transactions, such as a check-writer that uses a query to decide the amount of the check to be written.
Thus, normally, an end user interact with an ACCOUNTS system by creating transactions and querying attributes. When setting up an ACCOUNTS system for a business, or changing an ACCOUNTS system in response to changes in business rules, however, a user may be required to, for example, add or change the definition of transactions, accounts, or attributes. These types of interactions are traditionally accomplished by programming, which requires the user to enter or modify program code and to recompile the code to generate executable programs.
It is therefore desirable to provide a computerized system in which new or modified programs may be composed without entering, modifying or recompiling any program code. It is further desirable to provide such a system that employs a graphic user interface. It is also desirable to provide such a system in which changes in business rules may be tracked over time and appropriate business rules may be applied to transactions processed at a given time.